Proposed Boot Sequence

Please email all suggestions and comments to Guy Thornley

The new redefined boot sequence

As a result of some discussions on the mailing lists available, the boot loaders job has be totally redefined. This was because it was intruding on the kernel's job, and was trying to do too much.

Here is the new proposed sequence.

The boot sector runs first. The job of this is extremly simple: Load a continuous block from the drive booted from. What this will load is an old DOS .COM format image, that all you DOS coders will know of. This is because at computer boot we are still in realmode and we don't want to have to do fixing up.
Next the boot loader runs. The 512 byte sector that the BIOS loads and runs I will refer to as the boot sector, and the code that loads and runs I will call the boot loader. This is the interesting part. Please see below for details on this, as this is the guts of the loader. In a nutshell, it loads the kernal image from disk, switches to 32 bit protected mode and chains to the kernel.
The kernal runs. At entry point, is will be in full real mode. Since the boot loader will have set up a GDT for the whole computer and a LDT for the kernel task, these addresses will be passed in a memory structure, along with a pointer to a basic file access interface that the kernel can use until it gets its own running.

That is a lot shorter and simpler for the last one, isn't it?

Details of the loaders guts

Ahh, details. Don't we just love them?

Note that all of this is as yet only proposed, nothing yet has been coding. That is slacking, I know. At least you get your chance to make suggestions!

When the loader is called by the boot sector, it will be running with CS anything and IP zero (0). Note that this is zero based not 100h based like a DOS .COM file. Other than that, the structure is identical.

The boot sector contains code to navigate a filesystem. Only one filesystem will be supported by any loader, and that will be the filesystem of the boot drive. Initally this will be forced to DOS FAT16, but as time progesses, other filesystems such as FAT32, ext2, and such will be supported to.

How am I going to support multiple filesystems? Easy. As part of the boot code, there will be a subdirectory for each filesystem. These subdirectories will be compiled/assembled independantly of the boot loader and placed in a library. Each of these is a seperate library, and each library must contain the expected interface functions such as fs_init() and openfile(). Then to make a loader with support for a particular filesystem, we just use the correct library for that filesystem.

Once the loader has established a basic filesystem interface, anything can happen. Initially, it will, in this order:

Set up an initial GDT for the computer, LDT for the kernel task. Page mapping [page frames, page tables etc] should be one of the first things provided by the kernel.
Load the kernel from the disk. This will be in the form of a aout image file, since one of those does not need fixing up. [It makes life easy.]
The computer will be placed into 32 bit protected mode.
The kernel entrypoint [provided by the aout header] will be jumped to.

However, since we have a basic filesystem, it could for example display a boot-up menu like Windows 95 can do to change the way the computer loads. It could also have interfaces for other operating systems on the same partition. eg: It could have DOS 6.x and the WOS kernel on the same FAT16 partition.

The kernel will have a different selector than the boot loader. This is so the entrypoint address specified in the aout image will be acknowledged. As a result of this, all pointers passed will be provided in a 64 bit format. The low 4 bytes [32 bits] is the offset into the passed selector, which is in the next 4 bytes. Note that the passed selecor is 4 bytes; the high two bytes should be ignored since they will probably contain random data. This size variable is provided only to observe 4 byte alignment to elimate chances of any strcuture alignment problems.

On the stack will be a 64 bit pointer to a memory area aligned to 4 byte boundaries. Contents of this structure include things like the 64 bit address of the GDT and IDT set up by the loader, and a address that can be called for a basic filesystem interface.

I am taking suggestions.

As the co-ordinator for the boot team, I feel it is my task to make sure that the most suitable method of loading the WOS operating system is chosen to run into as few hassles as possible later. This requires good planning of course, but if it is done right, it should be a piece of cake.

I am taking suggestions. Have your say on what would be best, and what should be performed. To have your say, send me an e-mail and say what you want. I will then modify this page appropriatly.

Watch this space!!
I look forward to your comments!!

Back to WOS Boot-up page